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Beschreibung 

• AAA Serversystem zur ef f izienten Zugangskontrolle und Adress- 
zuordnung 

5 Die Erfindung betrifft ein AAA (Authentif ication Authorizati- 
on Accounting, Serversystem und ein Verfahren zur Verwaltung 
eines Pools von logischen Adressen. 

10 Die logische Adressierung von Teilnehmern bzw. Hosts und die 
Verwaltung des zur Verftigung stehenden Adressraums be, Netz- 
verbunden und im Internet ist ein wichtiges Aufgabenfeld der 
Netzwerktechnik. Die notwendige Hardware fur die Verwaltung 
von logischen Adressen und zur Bereitstellung der entspre- 
15 chenden Funktionalitat bei der Adressvergabe ist haufig xn 

Form von AAA (Authentif ication Authorization Accounting) Ser- 
vern bzw. AAA Serversystemen gegeben. FUr die Adressverwal- 
tung durch Multiserversysteme mUssen Informationen uber die 
Adressvergabe, uber zur Verfugung stehende Ressourcen sowie 
20 Statusinformationen auf zuverlassige Weise mit einer hohen 

Ubertragungsrate zwischen den einzelnen Servern ausgetauscht 
werden . 

Bei der Einwahl von Teilnehmern in das Internet, z.B. mittels 
herkommlicher schmalbandiger Telefonverbindungen oder xDSL 
Technologie (DSL: Digital Subscriber Line), kontrollieren ub- 
licherweise AAA Server den Zugang zum Internet, die das 
RADIUS (Remote Authentif ication Dial-In User Service) Proto- 
koll verwenden und deshalb RADIUS Server genannt werden. 
30 Hierbei findet der Ubergang vom Telefonnetz zum Internet bzw. 
IP-Netz an einem Zugangsserver statt, der fur das Internet 
als Network Access Server (MAS) bezeichnet wird. Bevor fur 
einen Teilnehmer eine Verbindung aufgebaut wird, werden zwi- 
schen dem NAS und dem RADIUS Server mittels des RADIUS Proto- 
35 kolls Nachrichten ausgetauscht, urn die Identitat des Teilneh- 
mers und seine Zugangsrechte im RADIUS Server Uberprufen zu 
lassen. Ist die Antwort des RADIUS Servers positiv, d.h. der 
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Teilnehmer ist autorisiert, baut der NAS eine Verbindung zwi- 
schen IP-Net z und dem Teilnehmer bzw. seinem Internet- 
Endgerat auf. Dabei benotigt das Internet-Endgerat des Teil- 
nehmers eine eindeutige routbare IP-Adresse. Da der Vorrat 
5 der zur Verfiigung stehenden IP-Adressen beschrankt ist, ver- 
geben die meisten Internetdienste-Anbieter - im Folgenden als 
Internet Service Provider (ISP) bezeichnet - IP-Adressen nur 
fur die Dauer einer Internetverbindung an ihren Kunden, d.h. 
den Teilnehmer. Bei verschiedenen Internet-Sitzungen bekommt 

10 daher der Teilnehmer bzw. sein Internet-Endgerat in der Kegel 
verschiedene Internet-Adressen zugewiesen. Dem Internet Ser- 
vice Provider steht iiblicherweise ein IP-Adressbereich - im 
folgenden als Adresspool bezeichnet - zur Verfiigung, aus dem 
die Adressen fur die temporare Zuweisung an Teilnehmern ent- 

15 nommen werden. Ein Internet Service Provider kann auch iiber 
mehrere Adresspools verfiigen, beispielsweise um mehrere Ser- 
vicegruppen fur verschiedene Dienste bilden zu konnen. 

Die dynamische Zuordnung von IP-Adressen erfolgt ublicherwei- 

20 se entweder im Zugangsserver bzw. NAS oder im AAA Server bzw. 
RADIUS Server. Die Zuordnung von IP-Adressen in den Zugangs- 
servern bzw. NAS hat den Nachteil eines betrachtlichen Ver- 
waltungs- und Wartungsaufwandes bei Internet Service Provi- 
dern, die eine grofie Zahl von Zugangsservem betreiben. Ad- 

25 resspools mussen in jedem einzelnen Zugangsserver eingerich- 
tet werden. Bei groflen Internet Service Providern ist die An- 
zahl der zu versorgenden Zugangsservem betrachtlich und 
folglich der Auf wand bei Einrichtung und Anderung von Adress- 
pools erheblich. Zudem fehlt eine zentrale Kontrolle der lau- 

30 fenden Internet verbindungen und der dabei benutzten IP- 
Adressen. Beispielsweise fur Betreiber von Zugangsnetzwerken 
(Access Networks), die den Zugang an kleinere Internet Servi- 
ce Provider weitervermieten, ist eine zentrale Verwaltung und 
Vergabe der zur Verfiigung stehenden Adresspools von grofler 

35 Wichtigkeit. 
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Bei groBen Internet Service Providern ist deshalb tiblich, 
dass die Res sour cenverwaltung und damit auch die Verwaltung 
der IP-Adressen zentral durch einen oder mehrere hochleis- 
tungsfahige und hochverf ugbare AAA Server erfolgt. Unter 
„hochleistungsfahig* ist in diesem Zusammenhang die Fahigkeit 
gemeint, eine groBe Zahl an Zugangskontrollen pro Sekunde be- 
arbeiten zu konnen. 

Eine ubliche Realisierung fur eine hochleistungsf ahige zent- 
rale Steuerung ist mittels eines Multiserversystems. Dieses 
besteht in der Regel aus einer Anzahl von Einzelrechnern bzw. 
Servern, die mittels des IP-Netzwerkes miteinander verbunden 
sind. Diese Losung ist aufwandsarm, weil teure ausf allssiche- 
re Hardware oder Cluster software nicht erforderlich sind. Zu- 
dem ist das System durch die Hinzunahme weiterer Rechner 
leicht nach oben skalierbar. Aus Redundanzgrttnden zur Aus- 
fallssicherheit sollten die Einzelrechner in der Lage sein, 
Aufgaben anderer Rechner des Multiserversystems zu uberneh- 
men. Die Lastverteilung auf die verschiedenen Einzelrechner 
des Multiserversystems erfolgt beispielsweise durch die 
RADIUS Clients auf den Zugangsservern. 

FUr eine Verwaltung der IP-Adressen durch ein Multiserversys- 
tern mussen Inf ormationen uber die Vergabe von Adressen den 
Bedarf an Adressen und Zustandsinf ormationen tiber laufende 
und abgeschlossene Internetsitzungen gesammelt und den Ein- 
zelrechnern verfugbar gemacht werden. Wegen der Redundanzan- 
forderungen sollten die einem Einzelrechner zur Verfugung 
stehenden Inf ormationen auch wenigstens einem anderen Einzel 
rechner zugangig sein. Weiter ist dafiir zu sorgen, dass Ad- 
ressen durch verschiedene Einzelrechner nicht mehrfach verge 
ben werden. 

Diese Anf orderungen bei der Verwaltung von IP-Adressen durch 
eine Multiserversystem konnen beispielsweise dadurch erfiillt 
werden, dass die Einzelrechner des Multiserversystems durch 
einen zentralen Server, z.B. ein DHCP (Dynamic Host Configu- 
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ration Protocol) Server oder einen unter Verwendung von her- 
stellerspezif ischen Protokollen arbeitenden Server, mit IP- 
Adressen versorgt werden. Diese Losung hat folgende Nachtei- 
le: 

5 • Der Schutz des zentralen Servers gegen Ausfalle, z.B. 

durch Doppelung, ist in der Regel mit betrachtlichen Auf- 
wand verbunden. 

• Fiir eine zuverlassige Kommunikation zwischen dem zentralen 
Server und den anderen Rechnern des Multiserversystems 

10 sollten ausgetauschte Nachrichten quittiert werden. Da- 

durch wachst die zu bearbeitende Inf ormationsmenge mit der 
Anzahl der Rechner stark an. Die Skalierbarkeit, d.h. die 
Integration weitere Rechner in das Multiserversystem wird 
dadurch beeintrachtigt . 

15 • Eine erhohte Anzahl von Verbindungswiinschen fiihrt zu einer 
Zunahme des Datenverkehrs zwischen dem zentralen Server 
und den Einzelrechnern. Daher kann es zu Belastungsspitzen 
(Bursts) kommen, die Verzogerungen bei der Bearbeitung 
verursachen konne . 

20 • Der zentrale Server fiihrt haufig zu zusatzlichen Wartungs- 
aufwand. 

Zur Erhohung der Ausf allsicherheit gibt es die Moglichkeit 
mittels eines erweiterten RADIUS Protokolls Zustandsinf orma- 
25 tionen direkt in den Zugangsservern bzw. NAS zu speichern, 

Diese Losung ist in dem RFC (Request for Comments) 2882 doku- 
mentiert, funktioniert aber nur fur Zugangsserver die die 
entsprechende Protokollerweiterung untersttitzen. 

30 Alternativ konnen die gesamten Inf ormationen liber Adresspools 
auf alien Einzelrechnern des Multiserversystems gespeichert 
und Nachrichten zur Koordinierung der Adressreservierungen 
zwischen den Einzelrechnern ausgetauscht werden. Diese Vorge- 
hensweise fiihrt zu einer erheblichen Volumen an auszutau- 

35 schenden Nachrichten, wenn Doppelvergaben von Adressen ver- 
mieden werden sollten. 
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Die Erfindung hat zur Aufgabe, die effiziente Verwaltung von 
einem oder mehreren Adressbereichen in einem AAA-Serversystem 
anzugeben, die die Nachteile herkommlicher Methoden vermei- 
det. 

Die Aufgabe wird durch eine AAA Serversystem nach Anspruch 1 
und ein Verfahren nach Anspruch 10 gelost. 

Das Erfindungsgemafie AAA Serversystem umfasst eine Mehrzahl 
von AAA Servern zu Verwaltung wenigstens eines Pools von lo- 
gischen Adressen. Dabei sind mehrere disjunkte Teilmengen 
bzw. Subpools wenigstens eines Adresspools jeweils genau ei- 
nem AAA Server zugeordnet. Die logischen Adressen der Teil- 
mengen des Adresspools sind jeweils nur durch den zugehSrigen 
AAA Server einem Endgerat bzw. Teilnehmer zuweisbar und wer- 
den von dem zugehorigen AAA Server verwaltet (Anspruch 1) . Es 
kennen auch mehrere Teilmengen eines Adresspools einem AAA 
Server zugeordnet sein. Bei den Adresspools kann es sich bei- 
spielsweise urn IP Adressbereiche handeln (Anspruch 2) . Die 
Zuweisung von Adressen zu Endgeraten durch die AAA Server des 
AAA Server systems kann beispielsweise mit Hilfe des RADIUS 
(Remote Authentication Dial-In User Service) Protokolls oder 
des DIAMETER Protokolls erfolgen (Anspruch 3) . Diese Proto- 
kolle werden haufig zur Kommunikation zwischen einem AAA Ser- 
versystem und einem Zugangsserver oder NAS verwendet, mit 
dessen Hilfe Endgerate mit dem Netz (z.B. Internet) verbind- 
bar sind. Die AAA Server des AAA Serversystems konnen bei- 
spielsweise mittels des Internetprotokolls bzw. TCP/IP 
(Transmission Control Protocol/Internet Protocol) miteinander 
kommunizieren (Anspruch 4 und 8) . Fur Anderungen der Zuord- 
nung von Teilmengen von logischen Adressen bzw. Subpools von 
logischen Adressen zu AAA Servern ist sinnvoll, wenn alle AAA 
Server des Serversystems uber den gesamten Pool bzw. die ge- 
samten Pools von logischen Adressen verftigen (Anspruch 5) . 
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Die Unterteilung von dem zur Verfugung stehenden Adressraum 
in Teilmengen und die Zuordnung dieser Teilmengen zu AAA Ser- 
ver erlaubt den Aufwand bei der Kommunikation zwischen den 
einzelnen Servern bzw. Rechnern zu reduzieren. 

Bei dem erf indungsgemafien Verfahren zu Aktualisierung von In- 
formationen in einem erf indungsgemaflen AAA. Serversystem wird 
von einem ersten AAA Server des Serversystem regelmaJUg eine 
Aktualisierungsnachricht an alle anderen Server des AAA Ser- 
versystems gesendet. Diese Aktualisierungsnachricht umfasst 
Informationen ttber Statusanderungen bei dem ersten AAA Server 
zugeordneten Teilmengen des Adresspools bzw. der Adresspools 
seit der vorhanden gegangenen Aktualisierung. Durch das re- 
gelmaflige, beispielsweise in festen Zeitintervallen vorgenom- 
mene Senden von Aktualisierungsnachrichten der AAA Server an 
alle anderen AAA Server des AAA Serversystems kann die Verga- 
be von logischen Adressen durch die einzelnen AAA Server des 
AAA Serversystems koordiniert werden. Die sich in Gebrauch 
befindlichen Teilmengen des Adresspools bzw. der Adresspools 
kSnnen so an alle AAA Server signalisiert werden. Zudem kann 
eine Information bezUglich der wahrend des nachsten Zeitin- 
tervalls benotigten Ressourcen an logischen Adressen zwischen 
den Servern AAA ausgetauscht werden. Dabei schatzt ein AAA 
Server vor dem Senden der Aktualisierungsnachricht die Anzahl 
der in Zeitraum zwischen der zusendenden Aktualisierungsnach- 
richt und der darauf f olgenden Aktualisierungsnachricht zu 
vergebenden logischen Adressen ab. Dies kann geschehen, indem 
das Produkt der maximal durch den AAA Server bearbeitbaren 
Rate an Anf orderungen fur die Vergabe einer logischen Adresse 
und der dem Zeitraum zwischen der zu sendenden Aktualisie- 
rungsnachricht und der darauf folgenden Aktualisierungsnach- 
richt gebildet wird (Anspruch 12) . Die so erhaltene Abschat- 
zung liefert eine obere Grenze fur die Anzahl der benStigten 



200205160 



7 

Adressen. Aus den dem Server zugeordneten Teilmengen des Ad- 
resspools werden welche fur die Entnahme der nach der Ab- 
schatzung in der Zeitraum benotigten logischen Adressen be- 
stimmt. Die Aktualisierungsnachricht kann dann Inf ormationen 
dartiber enthalten, welche dem AAA Server zugeordneten Teil- 
mengen der Adresspools fiir die Entnahme der nach der Abschat- 
zung in dem Zeitraum benotigten logischen Adressen bestimmt 
wurden (Anspruch 11) . Auf diese Weise kSnnen Teilmengen von 
logischen Adressen als "unsicher" markiert werden, d.h. dass 
eine Vergabe von logischen Adressen aus diesen Teilmengen in- 
nerhalb des nachsten Zeitintervalls moglich ist. Diese Mar- 
kierung spielt eine Rolle, wenn einzelne AAA Server zusatzli- 
che Teilmengen des Adresspools benotigen, urn die Verbindungs- 
anfragen zu befriedigen. In ein solchen Fall kann die Zustan- 
digkeit bzw. Zuordnung von nicht als "unsicher" markierten 
Teilmengen des Adresspools geandert und dem AAA Server mit 
Mangel an logischen Adressen zugeordnet werden (Anspruch 13) . 
Bei diesem Verfahren kommunizieren die einzelnen AAA Server 
eine Mischung aus redundanten Daten und Sperrinformationen 
(markierte Teilmengen des Adresspools, deren Zuordnung nicht 
zur Disposition steht) . Dadurch wird das Volumen der Daten, 
die zwischen den Servern ausgetauscht werden, beschrankt. Den 
einzelnen AAA Servern bleibt in Regelfall verborgen, welche 
Einzeladressen von anderen AAA Servern vergeben werden. 
Stattdessen werden die Teilmengen kommuniziert, aus denen Ad- 
ressen vergeben werden. Die auf den einzelnen Rechnern zu 
speichernden Statusinf ormationen ist dadurch reduziert - be- 
ztiglich anderer AAA Server wird der Status von (evtl. indi- 
zierten) Teilmengen statt der einzelner Adressen festgehalten 
- und die Datenrate des Informationsaustausches zwischen den 
einzelnen Servern wird reduziert. 
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Bei Ausfall eines AAA Servers k6nnen die diesem AAA Server 
zugeordneten Teilmengen des Adresspools einem anderen AAA 
Server, z.B. nach Mafigabe einer Prioritatsliste, zugeordnet 
werden (Anspruch 14 und 15). Evtl. werden die Teilmengen des 
ausgefallenen Servers auch zwischen mehreren anderen AAA Ser- 
vern verteilt. Es ist dann sinnvoll, Teilmengen von logischen 
Adressen, die bei der letzten erhaltenen Aktualisierungsnach- 
richt des ausgefallenen Server als „unsicher" markiert wur- 
den, fur eine Zeitspanne nicht fur die Neuvergabe von logi- 
schen Adressen zu nutzen (Anspruch 16) . Diese Zeitspanne kann 
beispielsweise der maximale erlaubten Verbindungsdauer ent- 
sprechen (Anspruch 17) . Aktualisierungsnachrichten konnen 
auch beim Neubooten von AAA Servern des AAA Serversystems 
verwendet werden. Beispielsweise ubermittelt ein neugeboote- 
ter AAA Server an die anderen AAA Server eine Multicastnach- 
richt, mit der er die Ubersendung von Aktualisierungsnach- 
richten und die Zuordnung von Teilmengen des Adresspools an- 
fordert (Anspruch 18) . Als Transportprotokoll zu Vermittlung 
von Aktualisierungsnachrichten konnen das TCP/IP Protokoll, 
das RADIUS Protokoll oder DIAMETER Protokoll verwendet wer- 
den. Durch das reduzierte Volumen an ausgetauschten Nachrich- 
ten ist es mSglich, dass die einzelnen Server des Serversys- 
tems an verschiedenen Orten d.h. dezentral aufgestellt werden 
(Anspruch 9) . 



Weitere vorteilhafte Weiterbindungen des Erf indungsgegenstan- 
des sind in den weiteren Unteranspruchen angegeben. 

Im folgenden wird die Erfindung im Rahmen eines Ausfiihrungs- 
beispiels anhand von fiinf Figuren naher erlautert. Es zeigen: 

Fig. 1: Ein Szenarium fur die dynamische Zuordnung von Adres- 
sen fur Internetsitzungen. 
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Fig. 2: Die Aufteilung eines Adressbereiches bzw. Adresspools 
in Teilmengen bzw. Subpools. 

Fig. 3: Die Zuordnung von Teilmengen an logischen Adressen zu 
RADIUS Servern. 

Fig. 4: Den Austausch von Aktualisierungsnachrichten zwischen 
drei RADIUS Servern. 

Fig. 5: Die verschiedenen Schritte bei der Anforderung einer 
zusatzlichen Teilmengen an logischen Adressen. 

Im Rahmen des Ausfuhrungsbeispiels wird angenommen, dass ein 
Oder mehrere IP Adressbereiche durch ein RADIUS Serversystem, 
d.h. eine Multiserversystem, das mittels des RADIUS Proto- 
kolls arbeitet, verwaltet werden. Das RADIUS Serversystem be- 
steht aus mehreren RADIUS Servern, die mit Hilfe eines Netz- 
werkes verbunden sind. Spezielle Software, z.B. Clustersoft- 
ware, wird nicht benotigt. Der Einfachheit halber wird ange- 
nommen, dass im Rahmen des Ausfuhrungsbeispiels ein Adress- 
pool einem' IP Adressbereich und Teilmengen des Adresspools 
Teilbereichen von IP Adressen entsprechen. Ein globaler Ad- 
ressbereich bzw. Adresspool kann einem Internet Service Pro- 
vider zugeordnet sein oder fur bestimmte Dienstklasse reser- 
viert werden. 

Im Figur 1 sind Internetendgerate Hostl, Host5 darge- 

stellt, uber die Teilnehmer eine Verbindung zum Internet INT 
aufbauen kbnnen. Mit Hilfe des IP (Internet Protokolls) Pro- 
tokolls IP, das uber dem PPP (Point-to-Point Protocol) Proto- 
koll PPP lauft, kann eine Verbindung zwischen dem Endgerat 
Hostl . . . Host5 und einem Zugangsserver NAS hergestellt wer- 
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den. Bevor von dem Zugangs server eine Verbindung mit dem In- 
ternet INT hergestellt wird, wird eine Anfrage bei dem RADIUS 
Serversystem RADSS durchgeftihrt . Der Austausch von Nachrich- 
ten zwischen dem Zugangsserver NAS und dem RADIUS Serversys- 
tem RADSS erfolgt mit Hilfe des Radiusprotokolls RADIUS. Das 
RADIUS Serversystems RADSS verftigt tiber einen Pool IPPool von 
eigenen IP Adressen @IP1, . ..,@Ipn , die dynamisch fur den 

Zeitraum der Verbindung den Internetendgeraten Hostl, , 

Hostn zugeordnet werden. Nach Erhalt der Autorisierungsnach- 
richt durch das RADIUS Serversystem und der Zuteilung einer 
IP Adresse fur den Zeitraum der Verbindung baut der Zugangs- 
server NAS eine Internetverbindung ftir das anfragende Inter- 
netendgerat Hostl, . .., Hosts auf. 

In Figur 2 ist ein Adresspool A dargestellt, der aus dem Ad- 
ressbereich IP 1 bis IP N besteht. Dieser Adresspool A wird 
in drei Teilmengen Al, . - , A3 unterteilt, die den Teiladress- 
bereichen IP 1 bis IP I, IP J bis IP K, und IP L bis IP N 
entsprechen. Jeder der RADIUS Server verftigt tiber den gesam- 
ten Adresspool A, d.h. auf alien Servern ist der gesamte Ad- 
ressbereich gespeichert. Jeder der RADIUS Server kann IP Ad- 
ressen jeder beliebigen Teilmengen Al, A3 von IP Adres- 
sen freigeben. Dagegen besteht ein exklusives Recht der Zu- 
ordnung von IP Adressen ftir Verbindungen, d.h. jeder RADIUS 
Server hat eine Oder mehrere Teilmengen Al, .., A3 von Adres- 
sen zugeordnet, aus der er IP Adressen vergeben kann. Diese 
Vergaberechte von IP Adressen konnen dynamisch zwischen den 
RADIUS Servern verschoben werden. In Figur 3 sind drei RADIUS 
Server RAD1, . . , • RAD3 dargestellt. Jedem ist ein Teilbereich 
von Adressen Al, A3 zugewiesen (durch durchgezogene 
Pfeile gekennzeichnet) , aus den er Adressen zuordnen kann. 
Alle drei RADIUS Server konnen bemitzte Adressen freigeben, 
was durch durchbrochene Pfeile gekennzeichnet ist. 
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In Figur 4 ist gezeigt, wie bei den einzelnen RADIUS Servern 
die Aktualisierung von Informationen uber den Status der an- 
dere RADIUS Server vorgenommen wird. In regelmafiigen Zeitab- 
standen sendet jeder RADIUS Server RAD1, . .., RAD3 eine Aktu- 
alisierungsnachricht an alle andern RADIUS Server RADl, 
RAD3, urn uber Anderungen beztiglich der zugeordneten Teilmen- 
gen an Adressen zu Inf ormieren. Diese Aktualisierungsnach- 
richt wird mit Hilfe von einem IP Multicastmechanismus ver- 
sendet und betrifft nur Teilmengen, hinsichtlich der sich 
seit der letzten Aktualisierungsnachricht eine Anderung erge- 
ben hat. Aktualisierungsnachrichten werden nicht quittiert. 
Die Doppeltvergabe von IP Adressen ist ausgeschlossen, weil 
schlimmstenfalls eine Freigabeinformation verloren geht, d.h. 
eine Information, die eine bereits benutzte IP Adresse be- 
trifft. Die Freigabe erfolgt dann spater, nachdem der Timer 
fur die maximale Vergabezeit ausgelaufen ist. Zusatzlich ent- 
hait die Aktualisierungsnachricht Informationen uber die 
Teilmengen von Adressen, aus welchen voraussichtlichen im 
folgende Zeitintervall IP Adressen vergeben werden. In Frage 
kommen dabei Teilmengen, die noch nicht vergebene IP Adressen 
zu Verfiigung haben. Entsprechend Figur 4 sendet RADIUS Server 
RAD1 zu den Zeitpunkten Sl.l und SI. 2 Aktualisierungsnach- 
richten UpdtRADl (fur: Update von RAD1) an die RADIUS Server 
RAD2 und RAD3. Zu verschobenen Zeitpunkten S2 . 1 und S2.2 bzw. 
S3.1 und S3. 2 senden der RADIUS Server RAD2 bzw. RADIUS Ser- 
ver RAD3 Aktualisierungsnachrichten UpdtRAD2 bzw. UpdtRAD3 
jeweils an die beiden anderen RADIUS Server RAD1 und RAD 3 
bzw. RAD1 und RAD2 . 



Auf jedem der RADIUS Server RAD1, RAD3 werden folgende 

Informationen gespeichert, die den gesamten bzw. globalen Ad- 
resspool A betreffen: 



200205160 




12 

• ein Bezeichner fur den globalen Adresspool A fur den Fall, 
dass mehrere globale Adresspools, beispielsweise fur ver- 
schiedene Dienstklassen, verwendet werden. 

• Eine Liste von den RADIUS Servern RAD1 , . ., RAD3, die 
Zugriff auf Adressen des globalen Adresspools A haben. 
Diese Liste beinhaltet die IP Adresse jedes RADIUS Servers 
RAD1, RAD3, einen Bezeichner ftir jeden RADIUS Server 
RAD1, . ., RAD3, den Zeitpunkt der letzten Aktualisierung 
ftir jeden RADIUS Server RAD1, RAD3 und die Gesamtzahl 
der aktuell freien, d.h. nicht vergebenen IP Adressen. 

• Die erste IP Adresse des globalen Adressbereichs A. 

• Die Anzahl von IP Adressen, die zu diesem Adressbereich A 
gehoren. 

• Die Zeitspanne zwischen zwei Aktualisierungen. 
Die maximale Zeitdauer, die fur die Verbindung eines In- 
ternetendgerats vorgesehen ist. 

Die Liste der Teilmengen von IP Adressen, beispielsweise 
in Form von Pointers, die jeweils auf die erste IP Adres- 
sen des Teilbereichs zeigen. 

Optional eine Liste von Zugangsservern bzw. Portkennungen . 
Diese Liste enthalt alle verbundenen NAS in Form Ihrer IP 
Adressen oder Ihrer NAS Kennungen und ihrer Portzahlen. 
Fur einen globalen Adresspool A kann zusatzlich ein Flag 
definiert werden, dass einen Mangel an freien IP Adressen 
anzeigt. Dieses Flag wird beispielsweise gesetzt, wenn die 
Gesamtzahl der freien IP Adressen kleiner wird als ein 
Schwellenwert, beispielsweise die Zeitspanne zwischen Ak- 
tualisierungen multipliziert mit der maximalen Rate an An- 
fragen nach IP Adressen. Das Setzen des Flags wird riick- 
gangig gemacht, wenn die Anzahl der freien Adressen wieder 
den Schwellenwert ubersteigt. 
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Folgende Informationen bezuglich der Teilmengen von Adressen 
werden auf alien RADIUS Servern gespeichert: 

• Der Bezeichner des RADIUS Servers, der fur die Teilmenge 
an Adressen verantwortlich 1st, d.h. der AAA Server, der 
aus dieser Teilmenge IP Adressen vergeben kann. 

• Die erste IP Adresse der Teilmenge bzw. des Teilbereiches 
an IP Adressen. 

• Die Anzahl der von der Teilmenge umfassten IP Adressen. 




Die auf den AAA RADIUS Servern vorgehaltenen, auf die Teil- 
mengen an Adressen bezogenen Inf ormationen werden in regelma- 
fiigen Zeitabstanden aktualisiert . Die Aktualisierung wird v 



ausgeiest durch das Ablaufen eines Timers, der das Zeitinter- 
vall zwischen zwei Aktualisierungsnachrichten misst. Von dem 

15 RADIUS Server, der Aktualisierungsnachrichten hinsichtlich 
des Status seiner Teilmengen an Adressen sendet, werden die 
freien, d.h. nicht vergebenen Adressen, der zugeordneten 
Teilmengen an Adressen bestimmt und die Teilmengen, welche 
innerhalb des nachsten Zeitintervalls zur Benutzung in Frage 

20 kommen, identif iziert . Die Aktualisierungsnachricht umfasst 

dann die Kennung des Radiusservers, von dem die Nachricht ge- 
sendet wird, die Gesamtzahl der freien IP-Adressen dieses 

» RADIUS Servers, die Kennungen bzw. Bezeichner der Teilmengen 
an Adressen, die fur eine Benutzung innerhalb des nachsten 
Zeitintervalls in Frage kommen, d.h. die als ^nsicher* mar- 
kiert sind, Anderung hinsichtlich der Benutzung von Teilmen- 
gen seit der letzten Aktualisierungsnachricht und gegebenen- 
falls weitere Statusinf ormationen. Nach dem Senden der Aktua- 
lisierungsnachricht wird der Timer neu gestartet. Ein RADIUS 
30 Server, der eine Aktualisierungsnachricht erhalt, setzt einen 
Oberwachungstimer neu, der misst, wie viel Zeit seit der 
letzten Aktualisierungsnachricht verstrichen ist. Anhand der 
empfangenen Aktualisierungsnachricht bringt der RADIUS Server 
die Statusinformationen tiber den sendenden Radiusserver auf 
35 den neusten Stand. 
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In Figur 5 ist der Austausch von Nachrichten zur und wahrend 
der Verbindung eines Teilnehmers bzw. Endgerats dargestellt. 
Von einem NAS (Network Access Server) wird fiir die Verbindung 
eines Internetendgerates eine Authentif izierungsanf rage rAUTH 
mit Hilfe des Radiusprotokolls RADIUS an einen RADIUS Server 
RAD1 gerichtet. Diese Authentif izierungsanf rage rAUTH enthalt 
die Kennung des NAS, den Bezeichner des Ports und die Kennung 
des Teilnehmers bzw. Endgerates. Von dem RADIUS Server RAD1 
wird eine Anfrage rLDAP an eine LDAP (Lightweight Directory 
Access Protocol) -Datenbank LDAP gestellt, im Zuge derer die 
Kennung bzw. Identitat des Teilnehmers ermittelt wird. Von 
der LDAP-Datenbank LDAP wird in der Antwort aLDAP die Kennung 
der Teilmenge von Adressen mitgeteilt, aus der die IP-Adresse 
zu entnehmen ist. Daraufhin wird eine IP-Adresse aus dieser 
Teilmenge von IP-Adressen bestimmt. Anschliefiend teilt der 
RADIUS Server die bestimmte IP-Adresse dem NAS in einer Ant- 
wort aAUTH auf die Authentif izierungsanf rage mit. Die Tatsa- 
che dieser neuen Verbindung wird den anderen Radiusservern 
RAD2 im Zuge einer Aktualisierungsnachricht UpdtRADl z.B. in 
Form einer aktualisierten Gesamtzahl an benutzten IP-Adressen 
und evtl. durch die Neumarkierung der entsprechenden Teilmen- 
ge an Adressen als ^nsicher* mitgeteilt. Analog erhalt der 
Radiusserver RAD1 wahrend der Verbindung Aktualisierungsnach- 
richten UpdtRAD2 von anderen Radiusservern RAD2 . Wenn die 
Verbindung unterbrochen werden soil, sendet der NAS eine 
Nachricht astop an den RADIUS Server, mit der die Abrechnung 
bzw. das Accounting fur die entsprechende Verbindung unter- 
brochen werden soil. Diese Nachricht enthalt die Kennung des 
Teilnehmers und die zugewiesene IP-Adresse. Der RADIUS Server 
RAD1 quittiert diese Nachricht dem NAS, wobei die Quittie- 
rungsnachricht ACKastop wieder die Kennung des Teilnehmers 
und die verwendete IP-Adresse enthalt. Nach Beendigung der 
Verbindung werden in der darauf folgenden Aktualisierungsnach- 
richt UpdtRADl die anderen Radiusserver RAD2 mit den entspre- 
chend aktualisierten Statusinformationen versorgt. 
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Wenn der RADIUS Server nicht uber genug Teilmengen an Adres- 
sen fiir die Anfragen durch Zugangsserver bzw. NAS verfugt, 
kann er die Zuordnung weiterer Teilmengen an IP-Adressen an- 
fordern. Eine derartige Anfrage bzw. Anforderung wird ausge- 
16st, wenn die Gesamtzahl freier IP-Adressen des RADIUS Ser- 
vers eine Schwelle unterschreitet, die beispielsweise durch 
das Produkt des Zeitintervalls zwischen Aktualisierungsnach- 
richten und der maximal bearbeitbaren Rate an Verbindungswiin- 
schen gegeben ist. In diesem Fall setzt der RADIUS Server ein 
Flag, das den Mangel an IP-Adressen anzeigt. Der RADIUS Ser- 
ver uberpruft anhand der Statusinformationen der anderen 
RADIUS Server, welcher Server die grofite Anzahl an freien IP- 
Adressen bzw. die groAte Anzahl an nicht markierten bzw. 
nicht benutzten Teilmengen an Adressen aufweist. Falls ein 
RADIUS Server identif iziert werden kann, der tiber betracht- 
lich mehr freie Adressen als den Schwellenwert fur Mangel an 
IP-Adressen verfugt, wird von dem RADIUS Server mit Adress- 
mangel eine Anforderung fur Zuweisung einer weiteren Teilmen- 
ge an Adressen gesendet. Mit Senden dieser Nachricht wird ein 
Uberwachungstimer gesetzt. Bei einer negativen Antwort sendet 
der RADIUS Server mit Adressenmangel eine entsprechende An- 
frage an andere RADIUS Server nach MaBgabe der dort freien 
Adressen. Falls kein RADIUS Server mit freien IP-Adressen in- 
fiziert werden kann oder wenn keine Antworten von den RADIUS 
Servern erhalten werden, wartet der RADIUS Server mit Adress- 
mangel wenigstens ein Aktualisierungszeitintervall, bevor er 
seine Anfragen wiederholt. Falls in diesem Zeitraum alle 
freien IP-Adressen vergeben werden, werden zusatzliche Au- 
thentifizierungsanfragen von NAS zuruckgewiesen. Wird dagegen 
eine positive Antwort auf die Anforderung einer neuen Teil- 
menge an Adressen erhalten, so wird diese positive Antwort 
mit einer Quittierungsnachricht an alle anderen RADIUS Server 
mittels Multicast quittiert und intern werden alle relevanten 
Daten aktualisiert . Dieser Mechanismus kann auch nach einen 
Reboot eines der RADIUS Server zur automatischen Rekonfigura- 
tion des RADIUS Servers verwendet werden. 
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Beim Ausfall eines der RADIUS Server wird durch eine Liste 
der Kennungen der RADIUS Server eine Hierarchie der Zustan- 
digkeit vorgegeben. Nachdem von dem ausgef allenen RADIUS Ser- 
ver keine Aktualisierungsnachrichten mehr erhalten werden, 
5 ubernimmt der RADIUS Server an der Spitze der Hierarchie oder 
der darauf folgende RADIUS Server die Kontrolle bzw. Verwal- 
tung der entsprechenden IP-Adressbereiche . Dabei laufen im 
RADIUS Server, der die Verwaltung der Teilmengen von Adressen 
ubernimmt, folgende Schritte ab: 

10 Die Obernahme von Adressen wird durch den Ablauf des Uberwa- 
chungstimers angestoBen. Danach wird eine Anforderung fttr ei- 
ne Aktualisierungsnachricht an den ausgef allenen RADIUS Ser- 
ver gesendet. Wenn darauf hin keine Antwort enthalten wird, 
werden mittels einer Multicast-Nachricht alle anderen RADIUS 

15 Server dariiber informiert, dass der RADIUS Server, der die 

Multicast-Nachricht sendet, die Verwaltung und Zuordnung der 
Teilmengen von Adressen des ausgef allenen RADIUS Servers u- 
bernimmt. Die Teilmengen von Adressen des ubemehmenden 
RADIUS Servers werden urn die ubernommenen Teilmengen von Ad- 

20 ressen erweitert. Dabei werden als „unsicher* markierte Teil- 
mengen blockiert und ein Timer fur die Blockierung gestartet. 
Dieser Timer misst die maximale Zeit fur die Zuordnung einer 
IP-Adresse fur eine Verbindung. Nach Ablauf des Timers wird 
die Blockierung der Teilmengen von Adressen zuruckgenommen. 

25 Nun sind alle Ressourcen an IP-Adressen wieder verfugbar und 
der Ausfall des RADIUS Servers ist vollstandig kompensiert. 
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Patentanspriiche 



1. AAA Serversystem (RADSS), umfassend eine Mehrzahl von AAA 
Servern (RAD1, RAD2, RAD3) , zur Verwaltung eines Pools (A) 
von logischen Adressen (IP1, . • .IPN) , 

dadurch gekennzeichnet, 

- dass mehrere disjunkte Teilmengen (Al, A2, A3) des Adress- 
pools (A) gegeben sind, 

- dass jede der disjunkten Teilmengen (Al, A2, A3) des Ad- 
resspools (A) genau einem AAA Server (RAD1, RAD2, RAD3) zuge- 
ordnet ist, und 

- dass die logischen Adressen der Teilmengen (Al, A2, A3) des 
Adresspools (A) nur jeweils durch den zugehOrigen AAA Server 

(RAD1, RAD2, . RAD3) einem Endgerat zuweisbar sind. 

2. AAA Serversystem nach Anspruch 1, 
dadurch gekennzeichnet, 

- dass die logischen Adressen (IP1, ...IPN) durch IP (Internet 
Protocol) Adressen gegeben sind. 

3. AAA Serversystem nach Anspruch 1 oder 2, 
dadurch gekennzeichnet, 

- dass von den AAA Servern (RAD1 , RAD2, RAD 3 ) des AAA Server- 
systems (RADSS) mittels des RADIUS Protokolls oder des 
DIAMETER Protokolls logische Adressen fur Endgerate zuweisbar 
sind. 

4. AAA Serversystem nach einem der vorhergehenden AnsprUche, 
dadurch gekennzeichnet, 

- dass zwischen den AAA Servern (RADl, RAD2, RAD3) des AAA 
Serversys terns (RADSS) Nachrichten mittels des Internet Proto- 
kolls austauschbar sind. 



5. AAA Serversystem nach einem der vorhergehenden Anspruche, 
dadurch gekennzeichnet, 
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- dass der gesamte Pool (A) von logischen Adressen 
(IP1,...IPN) auf alien AAA Servern (PAD1, RAD2, RAD3) des AAA 
Serversystems (RADSS) gespeichert ist. 

6. AAA Serversystem nach einem der vorhergehenden Anspruche, 
dadurch gekennzeichne t , 

- dass die Zuordnung von Teilmengen (Al, A2, A3) des Adress- 
pools {A) zu AAA Servern (RAD1, RAD2, RAD3) dynamisch ander- 
bar ist. 

7. AAA Serversystem nach einem der vorhergehenden Anspruche, 
dadurch gekennzeichnet, 

- dass mehrere Adresspools (A) von logischen Adressen gegeben 
sind, von denen disjunkte Teilmengen (Al, A2, A3) AAA Servern 
(RAD1, RAD2, RAD3) des AAA Serversystems (RADSS) zugeordnet 
sind, 

- dass verschiedene Dienstklassen gegeben sind, und 

- dass fur die Vergabe von logischen Adressen im Rahmen eines 
Dienstes einer der Dienstklassen eine Zuordnung von verschie- 
denen Adresspools (A) zu genau einer Dienstklasse gegeben 
ist . 

8. AAA Serversystem nach einem der vorhergehenden Anspruche, 
dadurch gekennzeichnet, 

- dass Nachrichten zwischen den AAA Servern (RAD1, RAD2, 
RAD3) des AAA Serversystems (RADSS) mittels des TCP/IP Proto- 
kolls austauschbar sind. 

9. AAA Serversystem nach einem der vorhergehenden Anspruche, 
dadurch gekennzeichnet, 

- dass wenigstens zwei der AAA Server (RAD1, RAD2, RAD3) des 
AAA Serversystems (RADSS) an unterschiedlichen Orten positio- 
niert sind. 



10. Verfahren zur Aktualisierung von Informationen in 
AAA Serversystem nach Anspruch 1, bei dem 
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- von einem ersten AAA Server (RADl, RAD2, RAD3) des AAA Ser- 
versystems (RADSS) regelmafiig eine Aktualisierungsnachricht 
(UpdtRADl, UpdtRAD2, UpdtRAD3 ) an alle anderen AAA Server 
(RADl, RAD2, RAD3) des AAA Serversystems (RADSS) gesendet 
wird, 

- diese Aktualisierungsnachricht (UpdtRADl, UpdtRAD2 , 
UpdtRAD3 ) Informationen uber Statusanderungen von dem ersten 
AAA Server (RAD1, RAD2 , RAD3) zugeordneten Teilmengen (Al, 
A2, A3) des Adresspools (A) seit der vorangegangenen Aktuali- 
sierungsnachricht (UpdtRADl, UpdtRAD2, UpdtRAD3) umfasst. 

11. Verfahren nach Anspruch 10, 
dadurch gekennz eichne t , 

- dass vor dem Senden der Aktualisierungsnachricht 
(UpdtRADl, UpdtRAD2, UpdtRAD3) im ersten AAA Server (RAD1, 
RAD2, RAD3) eine Abschatzung der im Zeitraum zwischen der zu 
sendenden Aktualisierungsnachricht (UpdtRADl, UpdtRAD2 , 
UpdtRAD3) und der darauf f olgenden Aktualisierungsnachricht 
(UpdtRADl, UpdtRAD2, UpdtRAD3 ) zu vergebenden logischen Ad- 
ressen durchgeftihrt wird, 

- dass dem ersten AAA Server (RADl, RAD2, RAD3) zugeordnete 
Teilmengen (Al, A2, A3) des Adresspools (A) fur die Entnahme 
der nach der Abschatzung in dem Zeitraum benotigten logischen 
Adressen bestimmt werden, und 

- dass die Aktualisierungsnachricht (UpdtRADl, UpdtRAD2, 
UpdtRAD3) zusatzlich Informationen dariiber enthalt, welche 
dem ersten AAA Server (RADl, RAD2, RAD3) zugeordnete Teilmen- 
gen (Al, A2, A3) des Adresspools (A) fUr die Entnahme der 
nach der Abschatzung in dem Zeitraum benotigten logischen Ad- 
ressen bestimmt wurden. 

12. Verfahren nach Anspruch 11, 
dadurch gekennz eichnet , 

- dass fur die Abschatzung das Produkt der maximal durch den 
AAA Server (RADl, RAD2, RAD3) bearbeitbare Rate an Anforde- 
rungen fttr die Vergabe einer logischen Adresse und der dem 
Zeitraum zwischen der zu sendenden Aktualisierungsnachricht 
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(UpdtRADl, UpdtRAD2, UpdtRAD3) und der darauf f olgenden Aktua- 
lisierungsnachricht (UpdtRADl, UpdtRAD2 , UpdtRAD3 ) gebildet 
wird. 

13. Verfahren nach einem der Ansprtiche 10 bis 12, 
dadurch gekennzeichne t , 

- dass der erste AAA Server (RAD1, RAD2, RAD3) tiberpruft, ob 
die entsprechend der Abschatzung benotigten Teilmengen (Al, 
A2, A3) des Adresspools (A) zur Verftigung stehen, und 

- dass bei negativen Ergebnis der Uberprufung durch den ers- 
ten AAA Server (RAD1, RAD2, RAD3) bewirkt wird, dass eine 
Teilmenge eines anderen AAA Servers (RAD1, RAD2, RAD3) dem 
ersten AAA Server (RAD1, RAD2, RAD3) zugeordnet wird. 

14. Verfahren nach einem der Anspruche 10 bis 12, 
dadurch gekennz eichnet , 

dass bei Ausfall des ersten AAA Servers (RAD1, RAD2, RAD3) 
die dem ersten AAA Server (RAD1, RAD2, RAD3) zugeordneten 
Teilmengen (Al, A2, A3) des Adresspools (A) einem zweiten AAA 
Server (RAD1, RAD2, RAD3) zugeordnet werden. 

15. Verfahren nach Anspruch 14, 
dadurch gekennz eichnet, 

dass der zweite AAA Server (RAD1, RAD2, RAD3) nach Mafigabe 
einer Prioritatsliste von AAA Servern (RAD1, RAD2, RAD3) be- 
stimmt wird. 

16. Verfahren nach Anspruch 11 und einem der Anspruche 14 o- 
der 15, 

dadurch gekennz eichnet , 

dass die entsprechend der letzten von dem zweiten AAA Server 
(RAD1, RAD2, RAD3) erhaltenen Aktualisierungsnachricht des 
ersten AAA Servers (RAD1, RAD2, RAD3) fur die Entnahme der 
nach der Abschatzung in dem Zeitraum benotigten logischen Ad- 
ressen bestimmten Teilmengen (Al, A2, A3) des Adresspools (A) 
bei Ausfall des ersten AAA Servers (RAD1, RAD2, RAD3) ftlr ei- 
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ne Zeitspanne nicht fur die Neuvergabe von logischen Adressen 
(IP1, IPN) genutzt wird. 

17. Verfahren nach Anspruch 16, 
5 dadurch gekennzeichnet, 

dass die Zeitspanne nach Mafigabe der maximal erlaubten Ver- 
bindungsdauer bestimmt wird. 

18. Verfahren nach einem der vorhergehenden Anspruche, 
10 dadurch gekennzeichnet, 

- dass ein zweiter AAA Server (RAD1, RAD2, RAD3) neu gebootet 

•wird, und 
- dass von dem zweiten AAA Server (RAD1, RAD2, RAD3) eine 
Multicast-Nachricht an alle anderen AAA Server (RAD1, RAD2, 
15 RAD3) des AAA Serversystems (RADSS) tibermittelt wird, wodurch 
die Obersendung von Aktualisierungsnachrichten (UpdtRADl, 
UpdtRAD2, UpdtRAD3) und die Zuordnung von Teilmengen (Al, A2, 
A3) des Adresspools (A) an den ersten AAA Server (RAD1, RAD2, 
RAD3) angefordert wird. 

20 

19. Verfahren nach einem der vorhergehenden Anspruche, 
dadurch gekennzeichnet, 

- dass als Transportprotokoll zur Obermittlung von Aktuali- 
sierungsnachrichten (UpdtRADl, UpdtRAD2, UpdtRAD3) das TCP/IP 

v M ^ Protokoll, das RADIUS Protokoll Oder das DIAMETER Protokoll 
verwendet wird. 
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Zusammenf assung 

AAA Serversystem zur effizienten Zugangskontrolle und Adress- 
zuordnung 

Die Erfindung betrifft ein AAA (Authentication, Authorizati- 
on, Accounting) Serversystem (RADSS) zur Verwaltung eines 
Pools (A) von logischen Adressen (IP1, IPN) und ein Ver- 

fahren zur Aktualisierung von Statusinformationen innerhalb 
des AAA Server systems (RADSS) . Das erf indungsgemafie AAA Ser- 
versystem (RADSS) umfasst eine Mehrzahl von AAA Servern 
(RAD1, RAD2, RAD3) . Jedem der AAA Server (RAD1 , RAD2, RAD3) 
sind eine oder mehrere disjunkte Teilmengen (Al, A2, A3) des 
Adresspools (A) zugeordnet. Ausgetauschte Statusinformationen 
bezuglich Adressvergabe betreffen die disjunkten Teilmengen 
(Al, A2, A3) von Adressen. Die Erfindung hat den Vorteil ei- 
nes aufwandsarmen und effizienten Nachrichtenaustausches zwi- 
schen den AAA Servern (RAD1, RAD2, RAD3) . Eine effiziente Al- 
lokation der Ressourcen an logischen Adressen wird durch be- 
darfsabhangige Anderungen der Zuweisung von Teilmengen (Al, 
A2, A3) von logischen Adressen (IP1, ipn) an AAA Server 

(RAD1, RAD2, RAD3) gewahrleistet . 
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